I recently found some great comments about a user commenting on ColdBox, why it exists, why create it, etc. I found it enlightening because, not many people have used this yet, it is fairly new to the open source community and it is my job to write more about the nature of ColdBox and using a coldfusion framework. So to introduce the article I have to note that ColdBox is another tool for web application development. Just like mach-ii and model-glue. Some people want competition and which one is the best. I do not believe in that. I believe in cooperation and finding the best solution to a problem, no matter what. I even wish that all the framework authors can join and create a solution. (Anybody listening?? A standard??) So please understand, that object oriented approaches and enterprise level application architectures will be complex and you should study upon them. Here is my article:Hi Jeff, Here are some observations about your comments, which are direct and to the point. I admire honesty and I truly believe that comments like yours are very constructive because nobody can be in my head or on other ColdBox application users and realize all the work that can be done or what ColdBox can do. So here are my comments:

"If you have to include the core files in every application you build, it isn't actually a framework."

You are always going to have to do includes to use a framework. It cannot magically be embedded in your code. You have to call it. If you are referring to the pre 1.1.0 installs, then you are right, the system folder had to be embedded in the application. Why? Because ColdBox started not as a full blown open source framework, but a robust object oriented architecture for high availability applications at my previous employer: Sandals & Beaches Resorts. Now you start seeing why I build my own from scratch. None of them fulfilled all my needs for my application, an online reservation system for hotel and airlines, which receives over 500,000 requests per day per server. The only one that I liked was fusebox, but it still did not meet my needs and at the time it was not implemented via CFC's. I did not start from scratch, I started from basic J2EE design patterns due to my c++ and java background, which are proven solutions, I also reviewed tartan, mach-ii, and model-glue. I like their MVC implementations but not their logic via the config file, no environment specific, no logging capabilities, no web application aspects where there. Config files,in my opinion, are about configuration and setup, not logic. All these frameworks, embedded some logic on their XML files. I believed that I could still go a step further and de-couple the logic in to objects. And that is what I did with the event handlers. This doesn't mean you don't have to setup your application via a config.xml file, you still have implicit calls which have to exist somewhere. There is no silver bullet for all these frameworks, nor will there ever be. You can use model-glue perfectly for a solution, but maybe it won't be good enough for another. These frameworks are tools, you must choose your tools depending on your requirements. How do you determine that then? Well, using it, build applications on it, see the benefit,load test them, etc. You cannot say that only because these frameworks exist before, that they could solve a project's requirements. I think that your comment saying that we don't need another framework does not have basis. I tried to use what was out there and they could not satisfy my requirements. Should I just try to patch them up? or really solve a problem that could be reused. ColdBox's roots are not open source and where not to replace or compete with these frameworks. I started doing proof of concepts back in July of 2005 for my online reservation system. One thing I have to tell you, that framework code has been scrutinized like you won't believe due to the nature of a mission critical application that is generating millions of dollars a day and it CANNOT GO DOWN. Another thing I saw is that ColdFusion also has a limit and several bugs where discovered thanks to this code. I can tell you that under extreme heavy load, cfsavecontent will start throwing java.lang.illegalState and null pointer expectations. However, ColdBox has become more than a framework, but also a developer toolkit. Which is something that you need to understand. It solves your issues of i18N, resource bundle usage, logging & auditing, web service integrations, and more. All those are aspects of a web application that you have reusable components to use or extend in your own application. In your comment about the blog application: Ray Camden's Blog was a mere port, another way of doing things. It does not mean, and I state throughout the docs, that an object oriented application following MVC design patterns should be written that way. That application has its own internal framework and logic. I merely decoupled and arranged the code. IT DOES NOT MEAN IT IS A COLDBOX APPLICATION. That would require re-writing the entire thing from the ground up in an object oriented way, and I really did not want to. Even if you port it to mach-ii or model-glue. It would still be the same, a port, not a fully oo design. About your comment on re-writing and application:

"if you have to rewrite the application, you're not using a framework!! What should have been done, is to extend an existing framework, with an interface."

If you are extending an existing framework to write an interface, you are re-writing the application. Mach-ii will make you adhere to their rules, model-glue to theirs. The logic of your application will change, the way to get/set variables will change. If you port an application from one framework to another, you will have to re-write and modify code. I did, for Brian Rinaldi's Illidium CFC Generator, from mach-ii to coldbox. It is more simple to do this, since the decoupling is done already. The business layer is separate, the views are separate. It is easier to convert from one framework to another, than from procedural code to a framework. No matter what you do Jeff, you have to re-write code. In my over 10 years of software engineering I have not yet seen something that I can plug and play without not re-writing or modifying at least one module. I don't believe a framework is just for organizing code like you say it does. Then why is Struts still going strong and impressive at the Enterprise level. It is an approach, a solution, to a common problem, it is de-coupling your logic from your presentations. This in turn gives you more flexibility and architectural leverage. You can maintain bigger and more complex applications this way. You can embed a J2EE business logic easily and transparently, trying doing that without a framework. You would have calls everywhere. You can create your business delegates and session facades with ease. I see a huge benefit of using a framework that maybe you have not been exposed too. ColdFusion in its roots was not oo. It can be now. Most major design patterns do apply to Coldfusion and decoupling and object oriented approaches are possible. Yes, they will make your application more complex, harder to grasp, and even WEIRD!! But that is the intent, to take your application to an Enterprise level. You can continue to build procedural code for certain applications, it doesn't mean its bad. But for high availability and enterprise applications, I would go with a framework. The flexibility and architectural extensibility that it will give you, cannot be found in other approaches. It will be hard to grasp and you might think, why do all this work, all these calls. Object Oriented architecture is not easy and you also have to note, that some complexity on these approaches, will make you sacrifice speed. But the benefits will be tremendous. Your comment about extending my XMLParser to read fusebox files? well, I believe it is a genius idea. Maybe someone can help me create a fusebox parser plugin, that can make coldbox and fusebox applications mingle with each other. I am all for that, extensibility.